Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(redshift): optionally reboot Clusters to apply parameter changes #22063

Merged
merged 25 commits into from
Feb 17, 2023

Conversation

dontirun
Copy link
Contributor

Closes #22009

Currently waiting on #22055 and #22059 for the assertions in the integration test to successfully run


All Submissions:

Adding new Unconventional Dependencies:

  • This PR adds new unconventional dependencies following the process described here

New Features

  • Have you added the new feature to an integration test?
    • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@gitpod-io
Copy link

gitpod-io bot commented Sep 15, 2022

@aws-cdk-automation aws-cdk-automation requested a review from a team September 15, 2022 19:52
@github-actions github-actions bot added effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. p2 labels Sep 15, 2022
await redshift.rebootCluster({ ClusterIdentifier: clusterId }).promise();
} catch (err) {
if ((<any>err).code === 'InvalidClusterState') {
return await executeActionForStatus(status, 30000);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about doing some sort of backoff here, but found checking every 30 seconds to be sufficient in my testing.

@dontirun dontirun changed the title feat(redshift-alpha): optionally reboot Clusters to apply parameter changes feat(redshift): optionally reboot Clusters to apply parameter changes Sep 20, 2022
@aws-cdk-automation
Copy link
Collaborator

This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

@dontirun
Copy link
Contributor Author

dontirun commented Oct 7, 2022

I was waiting on #22059 to be fixed before updating. I have manually confirmed (by looking at the cluster in the integration tests) that this works.

@dontirun dontirun force-pushed the feat-reboot-cluster-for-parameter-updates branch from 157b2ac to 52916e6 Compare October 19, 2022 16:41
@aws-cdk-automation
Copy link
Collaborator

This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

@mrgrain
Copy link
Contributor

mrgrain commented Dec 8, 2022

@dontirun The commented tests feel quite essential to this. I'm drafting this PR until you can get to it. Looks like a cool feature though. 🚀

@mrgrain mrgrain marked this pull request as draft December 8, 2022 13:20
@dontirun
Copy link
Contributor Author

dontirun commented Dec 8, 2022

@mrgrain I sadly couldn't get a few of things working with integ-tests library.

  1. The commented tests didn't work due to limitations with custom resource/lambda response size limitations (can't filter the response)
  2. Diff assets should be enabled, but I kept getting different asset hashes in the codebuild report although it would verify locally

@mrgrain
Copy link
Contributor

mrgrain commented Dec 8, 2022

@mrgrain I sadly couldn't get a few of things working with integ-tests library.

Hmm, we still need a way to verify the custom resource works. 🤔

  1. The commented tests didn't work due to limitations with custom resource/lambda response size limitations (can't filter the response)

The PR you've linked as been merged. Is something else missing?

  1. Diff assets should be enabled, but I kept getting different asset hashes in the codebuild report although it would verify locally

Why does it need to be enabled? But yes, it's weird you get a different hash.

@aws-cdk-automation
Copy link
Collaborator

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

3 similar comments
@aws-cdk-automation
Copy link
Collaborator

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

@aws-cdk-automation
Copy link
Collaborator

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

@aws-cdk-automation
Copy link
Collaborator

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

@aws-cdk-automation
Copy link
Collaborator

This PR has been in the MERGE CONFLICTS state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

Copy link
Contributor

@comcalvi comcalvi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very interesting feature! There's a few things I don't quite understand yet

ParameterGroupName: Lazy.string({
produce: () => {
if (!this.parameterGroup) {
throw new Error('Cannot enable reboot for parameter changes when there is no associated ClusterParameterGroup.');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting implementation details aside I didn't think it would be a good user experience to allow for enabling a feature that does nothing.

Using a Lazy gets around an order of operations error where enabling the feature and then later adding a parameter group would trigger this error (this test case)

@mergify mergify bot dismissed comcalvi’s stale review February 14, 2023 15:55

Pull request has been modified.

/**
* Whether the cluster will be rebooted when changes to the cluster's parameter group that require a restart to apply.
*/
protected rebootForParameterChangesEnabled?: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this prop, can we remove it? It seems redundant with rebootForParameterChanges?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to my other comment rebootForParameterChanges is the class property that is needed so we don't create duplicate custom resources with enableRebootForParameterChanges(). I thought it would be clearer to have this property versus making the Provider and CustomResource class properties

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add to this docstring that this is only used to guard against repeated invocations of enableRebootForParameterChanges()

Comment on lines 710 to 711
if (!this.rebootForParameterChangesEnabled) {
this.rebootForParameterChangesEnabled = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check on line 607 is all we need for this, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we need it to make sure we don't make a duplicate Custom Resource. I could create class variables to make the function idempotent, but thought that may be overkill

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

making the function idempotent is definitely overkill, and guarding against these potential bugs (an error would be thrown complaining about duplicate construct IDs) is definitely the right call in general. In this case though I don't see how the function could be called twice, as it's only called in the constructor and it's internal-only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally thought about making it constructor only, but It's currently not (example). I figured that exposing the method would be friendlier for situationally enabling the feature under specific conditions (ex. beta/prod stages, using the addToParameterGroup method and then using this method).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm okay. I don't love that we have this prop and this internal member, but it is a better user experience to be able to use a convenience method to set it, so we can leave it.

Please change the format of this to a guard clause though, eg:

    if (this.rebootForParameterChangesEnabled) {
      return;
    }
    this.rebootForParameterChangesEnabled = true;

…boot-handler/index.ts

Co-authored-by: Calvin Combs <66279577+comcalvi@users.noreply.github.com>
@mergify mergify bot dismissed comcalvi’s stale review February 14, 2023 20:50

Pull request has been modified.

Comment on lines 710 to 711
if (!this.rebootForParameterChangesEnabled) {
this.rebootForParameterChangesEnabled = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

making the function idempotent is definitely overkill, and guarding against these potential bugs (an error would be thrown complaining about duplicate construct IDs) is definitely the right call in general. In this case though I don't see how the function could be called twice, as it's only called in the constructor and it's internal-only.

Comment on lines 710 to 711
if (!this.rebootForParameterChangesEnabled) {
this.rebootForParameterChangesEnabled = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm okay. I don't love that we have this prop and this internal member, but it is a better user experience to be able to use a convenience method to set it, so we can leave it.

Please change the format of this to a guard clause though, eg:

    if (this.rebootForParameterChangesEnabled) {
      return;
    }
    this.rebootForParameterChangesEnabled = true;

/**
* Whether the cluster will be rebooted when changes to the cluster's parameter group that require a restart to apply.
*/
protected rebootForParameterChangesEnabled?: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add to this docstring that this is only used to guard against repeated invocations of enableRebootForParameterChanges()

@mergify mergify bot dismissed comcalvi’s stale review February 16, 2023 21:54

Pull request has been modified.

@dontirun
Copy link
Contributor Author

dontirun commented Feb 17, 2023

@comcalvi

I got around needing the rebootForParameterChangesEnabled internel member by using node.tryFindChild

    if (this.node.tryFindChild('RedshiftClusterRebooterCustomResource')) {
      return;
    }

@comcalvi
Copy link
Contributor

The node.tryFindChild() solution is perfect! Nice work

@mergify
Copy link
Contributor

mergify bot commented Feb 17, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 16ba85f
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot merged commit f61d950 into aws:main Feb 17, 2023
@mergify
Copy link
Contributor

mergify bot commented Feb 17, 2023

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/medium Medium work item – several days of effort feature-request A feature should be added or improved. p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

(redshift-alpha): reboot Clusters for Parameter updates
4 participants